1. The Field of the Invention
This invention relates to systems, methods, and computer program products for communicating SOAP messages using a User Datagram Protocol.
2. Background and Relevant Art
As computerized systems have increased in popularity, so also have the needs to distribute resources of computer systems in small networks, such as local area networks, as well as large or global networks such as the Internet. In general, computer systems and related devices exchange messages and distribute resources for a variety of reasons, whether, for example, to simply exchange personal electronic messages, to sell merchandise, provide account information, to share files, and so forth. One will appreciate, however, that as computer systems have become increasingly more sophisticated for individual use, the challenges associated with sharing data and resources on a network have also increased.
Historically, one problem with sharing data or resources among networked computer systems is that computer systems that use different operating systems could not easily share files or resources with another. This was ameliorated to some extent with certain scripting languages, such as Hypertext Markup Language (“HTML”), Extensible Markup Language (“XML”), and the like. These scripting languages allowed users to share files in a commonly-readable format with other users over a network using virtually any different type of operating system.
In one conventional example, a user shares an HTML file with another user on a network by communicating the HTML file to the other user through a network “connection” to the other user's computer. The connection typically involves a specific network link between the two computers using several layers of communication protocols on both the sending and receiving user's respective computer systems. For example, a connection between two users for transmitting an HTML file might involve use of the Hypertext Transfer Protocol (“HTTP”), which is layered on top of the Transmission Control Protocol (“TCP”), and which in turn is layered on top of the Internet Protocol (“IP”), and so on. Furthermore, the HTTP connection is typically directed between specific ports (e.g., port 80) on both the sending and receiving computer systems. Presently, there are many different ports and layered communication protocols that can be used on network-capable computer systems for sharing files and resources.
One can appreciate that as networked communication has increased among CD Air known and unknown parties, networks administrators are increasingly limiting the amount of files and resources available. For example, it is common now to allow outside access to files and resources only though a small number of commonly used communication protocols and/or communication ports, such as HTTP, UDP, and the like, or, for example, only allowing communication through a specific port. At least to address this and other concerns, Simple Object Access Protocol (“SOAP”) messaging was developed using XML, in order to allow cross-platform distribution of files and resources using a commonly allowed communication protocol—HTTP. Thus, SOAP messaging is becoming increasingly popular as a tool in distributed computing environments, even those involving relatively closed networks. Unfortunately, the protocols for communicating SOAP messages (e.g., HTTP, TCP, etc.) make SOAP messages inconvenient in some cases for certain functions of a distributed computing environment, particularly for such functions as identifying other available network resources.
For example, SOAP messages are typically transmitted using HTTP, which in turn uses a TCP connection between one computer and another computer to communicate data. To use SOAP to inquire whether a remote computer system on the network has an available service, a local computer would ordinarily need to request a one-to-one TCP connection with the remote computer. The remote computer would then have to accept the one-to-one TCP connection, and then receive another response from the local computer that the local computer is ready to communicate. Once this basic, three step process is completed, one or more SOAP queries and response could be communicated between the two computer systems, and files and resources could be shared where appropriate.
One can appreciate, therefore, that using SOAP messaging to identify available services on multiple remote computers on a network can involve a significant amount of resource overhead, as well as communication delay. In particular, the overhead of initiating a unique TCP connection (e.g., the three-step process) with multiple network computers could be impractical for a number of applications, such as using SOAP for real-time services, or for using services over long network distances. Furthermore, the one-to-one nature of connected communication is only part of the potential problem. For example, besides being an essentially one-to-one connection protocol, TCP has other features, such as error correction and retransmission of errant data, which can lead to additional communication delays.
By contrast, UDP, which is also a fairly common communication protocol, does not use connection-oriented communication, and so does not have the overhead associated with establishing a different, unique connection with each different remote IP Address and/or Port number of interest. Furthermore, UDP contrasts with TCP in that it allows for one-to-many data transmission, rather than one or multiple one-to-one connection-oriented communication sessions. In particular, UDP allows data packets to be sent to a single multi-cast address, which distributes the data packets to multiple other computers at multiple other corresponding addresses. Still further, UDP does not implement error checking functionality, and so does not run into some of the delay that might otherwise be associated with other protocols such as TCP.
Unfortunately, there are a number of different difficulties that make conventional UDP unsuitable for identifying available network services in a distributed computing environment, particularly doing so with SOAP messages. For example, UDP is not configured with request-response mechanisms that would be used for querying available services on a network, as UDP is basically a “send and forget” protocol. Furthermore, there is no present addressing scheme whereby SOAP can invoke a network address with UDP in the first instance. In particular, the present Universal Resource Indicators (“URI's”, such as “http://www.host.com/file”) used in SOAP messages typically invoke connection-oriented transfer protocols (e.g., “HTTP://”), which are layered on top of connection-oriented transmission protocols (e.g., TCP). Still further, UDP typically limits the size of data packets that can be communicated using UDP, which can create other difficulties with SOAP messaging.
Accordingly, an advantage in the art can be realized with systems, methods, and computer program products that allow the use of SOAP messages to be used to identify network resources in a distributed environment without necessarily requiring the overhead typically associated with connection-oriented communication. In particular, an advantage in the art can be realized with systems and methods that allow the use of SOAP messaging to implement UDP in a request-response fashion.